Bug Proofing Visual Basic: A Guide to Error Handling and Prevention
(Publisher: John Wiley & Sons, Inc.)
Author(s): Rod Stephens
ISBN: 0471323519
Publication Date: 11/01/98

Do not rely on testers to find your bugs. Catch them yourself before testers even see your code.

Have Someone Else Test Your Code

While you should perform the initial testing on your code, someone else should test it, too. If you understand the assumptions made internally by the code, you may not test those assumptions. Suppose your routine takes as parameters the start and end times for a person’s work day. If you work a fairly typical day, you may test the routine only using hours that might actually apply to you. You may not think that some people who work late-night shifts may have a start time (10 P.M.) that comes later than their start time (6 A.M.) the next day. A different tester who is unfamiliar with the code may make a different set of assumptions and uncover weaknesses in the code.

A different person can also take a more objective approach to testing. You naturally do not want your code to fail. Subconsciously you want the tests to fail to find any bugs. A separate tester can attack the code aggressively and wholeheartedly.

Don’t Shoot the Messenger

Do not take out your frustrations on the testers who find your bugs. They are just doing their part to improve the program. Testers do not cause bugs, they just find existing bugs that you should have found earlier. They are doing you a favor in exposing your bugs before customers find them. Testers deserve your thanks, not your anger. Do not blunt their enthusiasm for exposing bugs by treating them badly.

Fix Your Own Code

Once a tester identifies a bug in your code, you should fix it yourself. You know your code better than anyone else does, so it will be easier and safer for you to fix the bug.

Modifying code is a risky business. Changes introduce a greater number of bugs per line of code than original coding does. Understanding the entire routine and not just the bug makes changes much less risky. If you originally wrote the routine, you are most likely to understand it in its entirety. Someone else would be tempted to make the change without going to the trouble of mastering the complete routine.

Thank the tester who finds a bug in your code and then fix the bug yourself.

Simulate User Actions

To test large parts of the completed system, you can simulate many user actions using simple Visual Basic code. For example, to simulate a button click, you can invoke the button’s Click event handler. To simulate a change in a TextBox, set the TextBox’s Text property to a new value.

Using similar techniques, you can build test subroutines that exercise much of the system. To run the tests, you just need to invoke them and verify that the results are correct. In many cases, you can even verify the results automatically. For example, you can compare a TextBox’s new text contents to the value you know it should have.

The following code tests the ExpenseReporter application shown in Figure 14.4. It fills in a number of text values and verifies that the program calculates the correct totals in the TotalText, DueEmpText, and DueCompText fields.

Next, the routine invokes a menu command to present a preview of the printed expense report. The preview form, shown in Figure 14.5, is presented modally so the tester must verify that it is correct and then close it. The routine finishes by verifying that the preview process applied correct styles to the AmountText(0) field. That field was entered as “123.” The preview command should have changed it to “123.00” before displaying the preview form.

Figure 14.4  The ExpenseReporter application.

Private Sub MainFormTest_001()
    ' Set basic information.
    NameText.Text = "Stephens, Rod"
    IDText.Text = "1234"
    DeptText.Text = "671"
    ProjText.Text = "409"
    FromDateText.Text = "1/1/2001"
    ToDateText.Text = "1/1/2001"
    PrepaidText.Text = "111.00"
    AdvanceText.Text = "10.00"
    NotesText.Text = "Here is a note" & _
        vbCrLf & "that spans" & _
        vbCrLf & "multiple lines."

    ' Set expense detail line 0 information.
    DateText(0).Text = "1/1/2001"
    LocationText(0).Text = "New York -> Paris"
    CategoryCombo(0).Text = "Travel"
    DescrCombo(0).Text = "Plane"
    AmountText(0).Text = "123"

    ' Set expense detail line 1 information.
    DateText(1).Text = "1/1/2001"
    LocationText(1).Text = "Paris -> New York"
    CategoryCombo(1).Text = "Travel"
    DescrCombo(1).Text = "Plane"
    AmountText(1).Text = "456.78"

    ' Verify totals.
    If TotalText.Text <> "579.78" Then Stop
    If DueEmpText.Text <> "458.78" Then Stop
    If DueCompText.Text <> "0.00" Then Stop
    mnuFilePrintPreview_Click

    ' Verify number formats modified before
    ' the preview displays.
    If AmountText(0).Text <> "123.00" Then Stop
End Sub

Figure 14.5  The ExpenseReporter program’s preview screen.

Other user actions are harder to simulate. For example, the ExpenseReporter program displays the print preview screen modally. The test subroutine has no control while the preview is visible. That means it cannot easily examine the screen’s image to verify that it is correct. It also cannot easily close the preview automatically. The routine could perform these tasks using a timer, but that would make the test much more complicated. In general, these simulation techniques work best when the program uses no modal dialogs.

Some other more exotic operations are also difficult to simulate in Visual Basic. Mouse movement, mouse press and release, and key press and release events can be more complicated. If you really want to, you can even simulate many of these events using Visual Basic’s SendKeys statement, and the keybd_event and mouse_event API functions.

Finally, a Visual Basic 5 or 6 program can install a nonstandard WindowProc to read Windows messages directly. To test some of the more exotic messages this program might receive, you may need to send messages directly using the SendMessage API function.

Not all tests are simple enough that simulating them in this way is practical. However, it is worth the effort to simulate as many as possible. Simulations let you quickly and easily perform tests that otherwise might be quite time consuming. If the tests are easy to use, you and other developers are more likely to run them, while you might skip slower, manual tests.

Check Code Coverage

Use the code profiler that comes with Visual Basic to check the program’s code coverage. For more information on the profiler, see Chapter 15, “Code Profiler.”

In addition to giving performance statistics, the profiler can show you which lines of code are unused. Start the profiler and thoroughly exercise the program. Then examine any lines of code that were not executed. If it is possible to reach a line of code, expand your tests so they execute that line. If it is impossible to reach a line of code, remove it. Unused code indicates a possible bug.

Keep Testing

When you can find no more errors using your current tests, build some more tests using a different approach. If you still cannot find any bugs after trying all the techniques and strange special cases you can think of, stop.